Skip to content

Replace secretName with a secrets array on postgreSqlDatabases and mySqlDatabases - #193

Closed
willdavsmith wants to merge 3 commits into
mainfrom
willdavsmith-postgres-secret-reference
Closed

Replace secretName with a secrets array on postgreSqlDatabases and mySqlDatabases#193
willdavsmith wants to merge 3 commits into
mainfrom
willdavsmith-postgres-secret-reference

Conversation

@willdavsmith

@willdavsmith willdavsmith commented Jun 25, 2026

Copy link
Copy Markdown
Contributor

Description

Replaces the single secretName string on Radius.Data/postgreSqlDatabases and Radius.Data/mySqlDatabases with a secrets array annotated x-radius-secret-binding: true. Each entry is the resource ID of a Radius.Security/secrets resource (for example dbSecret.id):

resource postgresql 'Radius.Data/postgreSqlDatabases@2025-08-01-preview' = {
  name: 'postgresql'
  properties: {
    environment: environment
    application: myApplication.id
    size: 'S'
    secrets: [
      dbCredentials.id
    ]
  }
}

The mySqlDatabases change is identical in shape (same secrets array, same annotation, same required update).

Radius recognizes a property carrying this annotation as a list of secret bindings. For every listed secret it loads all of the secret's keys and exposes them to direct-module recipes as {{context.resource.secrets.<secretName>.<key>}}, where <secretName> is the secret resource's name and <key> is a key in its data. Platform recipes therefore consume real credentials without the developer ever placing them in the app definition.

Why an array of resource IDs instead of a single name string:

  • Natural, scalable shape. A database may need more than one secret (credentials, TLS material, …). A list of resource IDs handles that; a single magic name string does not.
  • Consistent with connections. Developers already reference other resources by .id; secrets now follow the same convention.
  • Namespaced, collision-free. Recipe references are qualified by secret name (...secrets.<secretName>.<key>), so multiple bound secrets never clash.

required is updated from [environment, secretName] to [environment, secrets] on both types. This is a metadata + schema-shape change to one existing property; the types' recipes are otherwise unchanged.

Important

This depends on the engine support added in radius-project/radius#12254, which introduces the x-radius-secret-binding annotation and the {{context.resource.secrets.<secretName>.<key>}} resolution path. The annotation is inert on engine versions without it, so this PR stays a draft until #12254 lands. Design context: radius-project/radius#12244.

Related GitHub Issue: N/A (tracked in radius-project/radius#12244 and #12254)

Testing

Exercised end-to-end by the manual resource-type verification workflow in radius-project/resource-types-verification — the Azure (Bicep AVM) direct-module flow registers each manifest, deploys a postgreSqlDatabases / mySqlDatabases resource whose secrets array points at a Radius.Security/secrets resource, and proves the injected secret value reaches the cloud database (the server's administratorLogin read-back matches the secret's username), then validates delete.

Contributor Checklist

  • File names follow naming conventions and folder structure
  • All properties in the Resource Type definition have clear descriptions
  • Required properties are listed in required: [] for every object property
  • Properties about the deployed resource are defined as read-only (readOnly: true)
  • Resource types and recipes were tested

Remaining checklist items (README docs, developer documentation, recipe authoring/idempotency, rad resource-type show) are unchanged from main — this PR only changes a single property's shape on two existing types.

Mark the secretName property with x-radius-secret-reference so Radius resolves the referenced Radius.Security/secrets resource and injects its values into direct-module recipe parameters (context.resource.secrets.<key>), rather than passing the literal secret name to the recipe. Mirrors the existing x-radius-sensitive precedent on Radius.Security/secrets.

Requires the engine support added in radius-project/radius#12254; the marker is inert on engine versions without it, so this stays draft until that lands.

Signed-off-by: willdavsmith <willdavsmith@gmail.com>
@github-actions

Copy link
Copy Markdown

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

Replace the secretName string property with a secrets array marked
x-radius-secret-binding. Each entry is a Radius.Security/secrets resource
ID; Radius loads every key of each listed secret and exposes it to the
recipe as context.resource.secrets.<secretName>.<key>, where <secretName>
is the secret resource's name.

This supersedes the earlier x-radius-secret-reference marker on secretName
and lets direct-module recipes inject developer-authored secret values
(admin username/password) into the provisioned database.

Signed-off-by: willdavsmith <willdavsmith@gmail.com>
@willdavsmith willdavsmith changed the title Add x-radius-secret-reference marker to postgreSqlDatabases secretName Replace secretName with a secrets array on postgreSqlDatabases Jun 26, 2026
Mirror the postgreSqlDatabases change: replace the single secretName string
property with a secrets array carrying x-radius-secret-binding, so MySQL
credentials are injected into the direct-module recipe via
{{context.resource.secrets.<secretName>.<key>}}. Lowercase the example secret
data keys (username/password) to match.

Signed-off-by: willdavsmith <willdavsmith@gmail.com>
@willdavsmith willdavsmith changed the title Replace secretName with a secrets array on postgreSqlDatabases Replace secretName with a secrets array on postgreSqlDatabases and mySqlDatabases Jun 26, 2026
@willdavsmith

Copy link
Copy Markdown
Contributor Author

Superseded by #197, which consolidates the secrets array change with the new x-radius-retain annotation on Radius.Security/secrets into a single draft PR. Closing in favor of #197.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant